/**
 * @file Streamer.h
 *
 * This file is the overall interface for the project.
 *
 * @author Luc Fourestier
 * @date 2009
 *
 * @mainpage The Streamer project
 *
 * This project is aimed to stream DVB from an input to an output and analyze it in the meantime.
 * No real decoding is involved, just packet transmission.
 * As input, it can take, for instance, file, UDP, TCP, stdin, RTP...
 * As output, it can take, for instance, file, info file, UDP, TCP, RTP...
 * The analysis part will read the stream (SI table...) and treat it according to the requested options.
 *
 * The Streamer project is based on the architecture and design described in @ref Arch.
 *
 * @page Arch The architecture and design
 *
 * @section Arch_NM The naming Convention
 *
 * @li We call "packet", a TS packet of 188 bytes.
 * @li We call "chunk", a integer number of TS packets (Commonly: 7 packets).
 * @li We call "stream", a continuous stream of contiguous packets (or chunks).
 * @li We call "buffer", a memory space where to put data temporarily.
 * @li We call "circular buffer", a certain number of contiguous buffers that can be written or read in a circular manner.
 * As most of the time chunks are stored in buffers of the same size, 'chunk' and 'buffer' expression can be miss-used.
 * @li We call "triplette", the combination of a StreamReader, a StreamAnalyzer and a StreamPlayer
 * linked together in order to treat ONE unique stream.
 * @li We call "stream pipe", a running "triplette".
 *
 * @section Arch_Overv The architecture
 *
 * In order to comprehend all kind of inputs and outputs, and also to be able to link them
 * independently from their type, the streamer has been done into three principle parts.
 * The StreamReader (input), the StreamAnalyzer and the StreamPlayer (output).
 * Those three parts are linked together around a circular buffer created by the streamAnalyzer and which
 * should be given to the two other modules at creation time.
 * Each modules can be instantiated as many times as we want (as long as we have memory enough!) but they
 * cannot live outside a "triplette".
 * In addition, an abstraction layer, the StreamPipe, has been created on top of theses modules in order to create/manage
 * the "triplettes" at once.
 *
 * @subsection Arch_Overv_SR The StreamReader
 *
 * The StreamReader is an input abstraction layer. It enables the user to open any kind of input
 * and push it to a StreamAnalyzer independently of the input type.
 * Indeed, the StreamReader cannot live alone, it needs to push the stream it is reading into
 * a StreamAnalyzer. That's why StreamReader always require the creation of a StreamAnalyzer prior
 * to anything else.
 * The StreamReader is based on a thread.
 * The StreamReader accepts options to rule it actions. By that way, user
 * can specify which type of input it wants to open (File, UDP...).
 *
 * @subsection Arch_Overv_SA The StreamAnalyzer
 *
 * The StreamAnalyzer analyzes the stream coming from the StreamInput in real time,
 * tags the chunk it reads and push them to a StreamPlayer.
 * The StreamAnalyzer is based on a thread and two circular buffers. The input circular buffer
 * is used by the StreamReader to push the stream into the StreamAnalyzer. The StreamAnalyzer thread
 * will then retrieve the data from the circular buffer one by one, analyze and push them to the StreamPlayer.
 * The output circular buffer is a 'tag' buffer which tags the chunks. Tags are important information for
 * the StreamPlayer in order to know what to do with the chunks.
 * When creating the streamAnalyzer, the caller can give options that will rule
 * the analysis and actions of this module. By this way, we can do different treatment on the stream
 * with one generic module.
 *
 * @subsection Arch_Overv_SP The StreamPlayer
 *
 * The StreamPlayer is an abstraction layer for the output. It enables to decouple the output type from the
 * stream itself. It is based on a thread and two circular buffers. The first one containing the chunks provided by the StreamReader.
 * The second one containing the 'tags' generated by the StreamAnalyzer. Those two buffers together form 'tagged chunks'.
 * The tagged chunks are then sent/dumped according to what is specified into the tags.
 *
 * @subsection Arch_Overv_Tag The tagging
 *
 * All the chunks that pass through this triplette are tagged; prefixed with a special tagging structure
 * (see Tag_s). This is initiated by the StreamReader and completed by the StreamAnalyzer. The StreamPlayer
 * reads them back to know what to do with the chunks (when to send them, for instance).
 *
 * @section Arch_Design The Design
 *
 * The version number of the Streamer library is a two-numbers notation: a major number representing major changes (ex: changes of API)
 * followed by a minor number representing minor changes (ex: bug fixes). The separator used in between has no importance, it
 * could be a dot '.', a coma ',' or anything else.
 * The version numbers can be read out from the Streamer.h file throughout the two following macros:
 * @li STREAMER_VERSION_MAJOR
 * @li STREAMER_VERSION_MINOR
 *
 * For instance, if the version is 2.14, STREAMER_VERSION_MAJOR would then be 2 and STREAMER_VERSION_MINOR, 14.
 *
 * @subsection Arch_Design_StPi The StreamPipe usage
 *
 * To use the StreamPipe facility, you call the SPI_create() function for creation and the
 * SPI_Delete() for deletion. To list the StreamPipes call the SPI_List() function.
 *
 * @subsection Arch_Design_Trip The triplette usage
 *
 * If a developer wants to create a stream pipe without using the StreamPipe facility, he must
 * FIRST create a StreamAnalyzer, then a StreamPlayer and a StreamReader passing them the
 * StreamAnalyzer circular buffer.
 * Here is the sequence:
 * @li 1- Fill the StreamAnalyzer options.
 * @li 2- call SA_Create()
 * @li 3- Fill the StreamReader options (the circular buffer options MUST be filled with the SA circular buffer).
 * @li 4- call SR_Create()
 * @li 5- Fill the StreamPlayer options (the circular buffer options MUST be filled with the SA circular buffer).
 * @li 6- call SP_Create()
 *
 * Now the triplette is created, the stream pipe is ready to start.
 *
 * If the developer wants to delete the triplette, he must call the deletion function in the opposite order. But be aware that
 * the deletion will be fully valid only when SA_Delete() will return. Indeed the StreamReader and
 * the StreamPlayer can stay blocked on the circular buffer until it is destroyed itself.
 *
 * @li 1- call SP_Delete()
 * @li 2- call SR_Delete()
 * @li 3- call SA_Delete()
 *
 * @subsection Arch_Design_SPI The StreamPipe
 *
 * Refer to @ref SPI.
 *
 * @subsection Arch_Design_SR The StreamReader
 *
 * Refer to @ref SR.
 *
 * @subsection Arch_Design_SA The StreamAnalyzer
 *
 * Refer to @ref SA.
 *
 * @subsection Arch_Design_SP The StreamPlayer
 *
 * Refer to @ref SP.
 *
 * @subsection Arch_Design_CB The circular buffer
 *
 * Refer to @ref CB.
 *
 */

#ifndef STREAMER_H_
#define STREAMER_H_

#define STREAMER_VERSION_MAJOR 0
#define STREAMER_VERSION_MINOR 1

#include "StreamAnalyser.h"
#include "StreamReader.h"
#include "StreamPlayer.h"
#include "StreamPipe.h"
#include "PAT.h"
#include "PMT.h"
//#include "PES.h"
#include "TS.h"


#endif /* STREAMER_H_ */
